home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 2⁄9⁄90 / 0627-Re More On UnloadAll-Feb90 < prev    next >
Encoding:
Text File  |  1990-02-09  |  1.6 KB  |  41 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    3578392                         6-Feb-90        13:28PST
  4.  
  5. From:   ROSENSTEIN1                     Rosenstein, Larry
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    RE>More On UnloadAllSegs
  10.  
  11. Attn:   MacApp Tech
  12. SentBy: Larry Rosenstein
  13. Date   2/6/90
  14. Subject    RE>More On UnloadAllSegs
  15. From   Larry Rosenstein
  16. To   MacApp Tech
  17.  
  18. Subject:  RE>More On UnloadAllSegs                      2/6/90       12:49 PM
  19. First, you can call UnloadAllSegs from other than the main segment, as long as
  20. it is called from a resident segment.  MacApp has a routine to mark segments
  21. resident, and you can use this dynamically to control which segments get
  22. unloaded by UnloadAllSegs.
  23.  
  24. In the case of reading a document, if you place your main document-reading
  25. code in a separate segment, then at the start of the read, you can mark this
  26. segment as resident.  After you read each part of the document, then you can
  27. call UnloadAllSegs to unload the segments used by that part.  It's not clear
  28. to me that UnloadAllSegs is time consuming compared to the code that reads a
  29. document from disk.  (The same is probably true of LoadSeg if the segment is
  30. still in memory.  Note that UnloadSeg doesn't purge the segment from memory.)
  31.  
  32. I think relying on every procedure to create a stack frame is dangerous.
  33. First, there are the assembler routines, which I don't think create a stack
  34. frame.  It's also possible that an optimizing compiler will not generate a
  35. stack frame if the routine has no local variables.  (I don't know if this is
  36. done currently, but it's certainly a possible optimization.)
  37.  
  38. Larry Rosenstein
  39.  
  40.  
  41.